圖片來源：Azure
本章節是整個產品的核心：系統設計
在章節開始之前，需要先了解清楚：
知道自己在做什麼很重要，筆者聽過一個謠言：『我覺得把這個功能技術做上去超讚的，知道的人一定會覺得我們技術好厲害。』，可惜的是，世界上99％的人不會知道，而少數那1%的人知道了，也只是花了1秒說：『喔，這邊有這個。』，然後這個功能價值就只有花很多時間換來的1%以內的人的1秒，造成了99%的人還在被其他糟糕的體驗延誤了好多個1秒。
因此了解產品核心是要要解決什麼樣現實的問題很重要。
在開發產品跟專案的前期，應該要有一個產品架構的原型，在各個節點上討論出模擬事件而做出彈性，多餘而華麗的東西非常冗余且損耗成本，但彈性的範圍拿捏在考量產品的週期上很考驗團隊經驗。
初期設計以筆者的觀點應該要有幾個原則（歡迎補充）：
前期的原則其實適用到整個產品專案的生命週期，每個人對於每個產品流程理解不同，但就如開篇所說的，找出最適合自己產品的架構最重要。
相信很多人都有多多少少接觸過寫網頁這塊，這塊能大能小，大可以大到整個公司都是網頁起家做到連無人機都有（如 Amazon)，小可以小到用txt檔案寫html，放在瀏覽器上覺得自己會寫網站了。
因此筆者先以網站的概念來簡單設計一個 Serverless web app的架構。
上面這張圖來自於Azure的說明文件，代表一個基本的網站應該會使用到的所有服務。
從傳統的Server觀念來看，一台Server基本上會處理連線傳入的時候指定的Port跟Path，網頁伺服器會根據路由的概念來處理使用者是需要網站靜態資料、設計好的API邏輯還是拿取其他硬碟上的檔案資料。
在上面這張圖來說明，基本上除了 CDN(Content delivery network) 服務以外，涵蓋了一個傳統Server架設網站上應該會具備的功能及服務，
圖片來源：Medium
通常網站伺服器連線傳入會由 Nginx, IIS 或 Apache 等Web伺服器層接收並交由WSGI(Web Server Gateway Interface)等應用伺服器層級傳給Web框架層級來做邏輯處理。
下面是Flask框架邏輯處理常見的簡單函數
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
return 'Hello, World!'
一個簡單處理單次請求的API要考量Nginx等伺服器層面設定、應用伺服器層級轉發及程式框架的路由設定，而這些設定在小型網站上可能很迅速，但是再逐漸拓展的產品上，維護性跟彈性就會越來越差，非常考驗程式設計人員的系統思維，這都還沒有考量高負載、高併發及多台Web主機溝通的問題。
而在成本上，除了高昂架設成本（主機環境等）以外，持續部署的時間累積的成本某種程度下會比用多少花多少的 Serverless 高。
乍看之下所有系統都是自己架，成就感很高，但實際上價值很低。
圖片來源：Azure api management
今天在雲端上，處理一次的請求，只要在Azure api management這個服務上，設定好每一個請求都是指向哪個資源：存取靜態網站交由 Azure CDN所託管的網站頁面檔案庫、邏輯問題由每一個寫好的Azure Functions 處理並存取 Azure SQL。
圖片來源：火影忍者
而在非常大量的請求下，設定自動拓展規則的話，Api management服務會複製好幾份自己出來處理這些問題，而Azure Functions本身也支援平行處理，這個就有如影分身之術跟多重影分身之術的差異，一個是好幾個入口，結果做事的都是一個人；另一個則是好幾個入口，做事都是不同人。
我一個打不了十個，但你殺了一個我，還有千千萬萬個我。
產品架構上，只要把網頁放在Storage blob 邏輯放在Functions 把Api-management建好設定好路徑指向，就已經完成一個基本網頁了！但請注意，筆者說起來很輕鬆，實際後續的章節建議大家跟著實作，有些設定看似易用，陷阱遠比想到的還要多。就像是『冷啟動』等，會在Function實作的章節詳加解釋。
但 Serverless 不是萬能的，這些前提都是你的產品使用的地緣都在有網路的情況下。
雲端服務提供商處理的就是把這些複雜底層的問題抽象出來預設大部份產品涵蓋到的需求，減少繁瑣設定，並有限的客製化需要的額外選項，讓系統架構人員可以快速建構產品，並專注在真正在產品的邏輯層面上。但一開始定好產品的需求之後，怎麼根據需求去連結每一個雲端服務來設計系統結構，接下來連續幾天篇幅會帶大家套用常見的產品如電商、Chat-bot、IOT等產品常用的幾個服務跟設計考量，如果也有想知道某種產品應該會怎麼設計的也歡迎留言討論！
iThome鐵人賽
看影片追技術